Note: I'm not sure by which delivery method I'll be sending this package,
whether by snail-mail or on someone else's computer.  I don't have internet
access anymore, so any correspondence would be quite inconvenient. However,
here's what I have.

Note that I have included a directory (or tarball) named linkproblems.
There is a problem with link - or at least the version I have.  There
is a readme.txt included with it to explain it all.

Included in this are the sources for a c.prep, c.comp, and c.opt to
build a cross C compiler system for the COCO. I hope I've included
everything. I've given them the names co*, but you may use whatever
names you wish.

Quickly, I also have included very rough disassemblies of the mw-standard
clibs and also (one of) Cark Kreiders's clib.  They are very rough - very
few have had much done to them to improve their readability.  I've reverted
a couple or so to the original C source.  You may already have all this,
possibly in better form, but I thought I'd send them along, too.

I also have included a directory called "utils".  These are a few little
quick utilities I've developed to aid in my testing and studying of the
disassemblies.  Most are written in Perl, but Perl is available on all
major platforms (COCO and OSK excluded, AFAIK).

Now more info regarding the compiler:

coprep was modified from the cprep19 sources found on rtsi and elsewhere.
co_comp and co_opt are disassembled from the MW programs, so it's up
to you whether you wish to post them or not.

I've developed these packages to run under Linux, hopefully under MinGW,
and also seem to work alright under OSK.  I've tested them using the
sources for co_comp and co_opt themselves plus the sources for rma. (Also
the single source file for cc by Carl Kreider, et.al.).  I didn't do
extensive testing under either MinGW or OSK, just that the test files
compiled identically with those compiled on the COCO.

For OSK, I've not even tried to get cprep to work.  I made one modification
in the source and it accepts AFAICT files generated by OSK's cpp.  The
only difference I found was that when the source returned from an #include,
cpp used a code "#8" rather than the "#7" used by the COCO.  I'm not
sure if anyone would be interested in doing cross compiling on OSK, but
it seems like it's available if anyone desires.  My 25-MHz system compiles
pretty fast.

I've gotten them all to compile on all phases to files identical to that
generated on the COCO.  Some sublte bugs may still pop up.  Hopefully
I've commented things well enough that someone can fix anything that
shows up.

I really haven't gotten things as well along as I'd have liked to. It's
taken me quite a while (since somewhere around the first of the year) to
get this far.  I had it working correctly (except for some things that
popped up from time to time for a month or so, but I've been going back and
renaming functions and variables to more useful names.  I haven't done as
well as I'd have liked in this respect, but I'm getting a bit burned out
from all the time I've spent on the thing.  I've commented heavily (possibly
too much, but maybe this will make things easier for someone else to
understand.

There are several placed where I have added the tag FIXME into the comments.
You may wish to go to them and check all them out.  Many don't need any
fixing (I think) but some may.  They are mainly tags to places that might
be of interest.

Floating point variables:

The file cocodbl.c is the source to handle conversion to COCO-style
floating-point numbers.  It was taken from the original MW sources.
Possibly I should have used the Kreider libs.  I don't know what is
considered the best or standard, or whatever.  I _THINK_ I have it
fairly bullet-proof, although I've thought that 3 or 4 times and
some bug would pop up, but hopefully, it's fairly correct now.  I've
left most of the coco assembly source from the lib (as comments) as
guides.  You may wish to remove some of them.  Actually, if you do wish
to post this publicly, you might want to archive what I've sent you and
then do some cleanup.  That's all up to you.

Oh, one place you might want to look at first is in comp_14.c, at the begin
of funcmain().  I found what's actually a bug in c.comp - or at least
it does things differently than all the other compilers I'm using, but
it might be useful to leave it as was.  I modified it but you might wish
to put it back as was.. Check it out and see what I mean.

Cprep _may_ need some more fixing.  I didn't spend a lot of time with it,
just got it to work, fixing anything that popped up, but it may need
some more fixing.  There were some placed in it where segfaults would
occur.  It could have been messing up the COCO all along but just wasn't
showing up.  Actually, in all the code - c.comp, especially, I encountered
some segfaults where a struct pointer was null, or pointing to some area
not within the accessible areas, and, of course Linux would bail with a
segfault.  Not sure what was going on with the coco.  I've tried to do
work-arounds for each case I've found.
Actually, I've noticed something with my XMESS emulator. If I'm using
the compiler (or something) in the morning, I suddenly see the time set
as the afternoon.  Not sure if it's the emulator or one of the compiler
components is doing it.. Oh, well..

I thought I'd compose this message and then put everything together.
I hope you find this useful and suitable for your purposes.  I have
tried to get something going with gcc, but it's such a job.  I prefer
to have the compiler to produce ROF's of the same type as the original.

Also, one problem I see is the fact that direct vars would have to be
built into gcc.  Without this, C compilation for the COCO would be
hampered.  As of gcc 3.something, all the slots for types were full,
but perhaps some type or class that the COCO didn't use could have
been stolen - not sure, but it would have been a big job (although
nearly a year spent on rebuilding the MW progs is a big job, too ;)

If someone wishes to devote more time to this project, there are a few
things that can be done.  One thing would be to rearrange some of the
functions within the file.  I've left them in the original order as it
might be useful to still compare the code to the original, but if some
of the static functions were moved to the top, many of the prototypes could
be eliminated.  If the group still wished to keep it compilable on the COCO,
a few things could be bettered.  The function memcpy() is available on the
COCO, so the function cpy_mem() could be eliminlated - actually, it probably
ought to be.  The copy functions in c.comp place src before dest, standard
funcs place dest first.  There is also one routine [p2_03_notused()] that
is not called.  It could be removed.  All these are left in to keep the
compiled code as much like the original as possible until we know we don't
need to be referring back to it.

One other thing.  I haven't tried to make this build work on the COCO.
There may be some places where it is not correct.  In fact, while I was
trying to put all this together for you, I came across a place dealing
with longs where I'd not provided for code for COCO.  Here is one area
where I made a change.  I assumed that all cross compilers would have
at least 8-bit int's, so I just stored them in the value member of the
cmdref (member cmdval).  The COCO would allocate memory for a double and
store a pointer in "cmdval".

For doubles - you can reference the code, I set up a struct with storage
for the host native double, and also a 4-byte array for the COCO-type
double.

I've eliminated most warnings in the build process.  I've left a few still
in, as these areas might need to be addressed.

Anyway, here it is.  I hope you can use it.  I didn't fool with
the cc frontend.  Surely someone can handle that.  It should be pretty easy
to adapt the public-domain versions for that.
